A computer network is a geographically distributed collection of interconnected communication links for transporting data between nodes, such as computers. By definition, a network is a group of computers and associated devices that are connected by communications facilities or links. Network connections can be of a permanent nature, such as cables, or can be of a temporary nature, such as connections made through telephone or other communication links. A plurality of computer networks may be further interconnected by intermediate nodes, or routers, to extend the effective “size” of the networks. A router is computer system that stores and forwards data packets from one local area network (LAN) or wide area network (WAN) to another. Routers see the network as network addresses and all the possible paths between them. They read the network address in a transmitted message and can make a decision on how to send it based on the most expedient route (traffic load, line costs, speed, bad lines, etc.). Routers typically communicate by exchanging discrete “packets” of data according to predefined protocols. In this context, a protocol comprises a set of rules defining how the nodes interact with each other.
The Asynchronous Transfer Mode (ATM) protocol establishes point-to-point connections over a virtual connection oriented media. A properly configured network device within an ATM system will include an ATM interface and a mechanism for establishing and supporting virtual connections or circuits. The appropriate hardware and/or software for providing ATM interfaces is generally known in the field. In 1991, an entity known as the ATM Forum was founded to standardize ATM technology. A substantial body of information regarding deployment of ATM technology is available from the ATM Forum. Cites to many references pertaining to ATM technology are available through the ATM Forum's World Wide Web site at www.ATMForum.com. Specific references include McDysan et al., “ATM Theory and Application,” McGraw Hill, 1995; Minoi et al., “ATM & Cell Relay Service for Corporate Environments,” McGraw Hill, 1994; and Prycker “Asynchronous Transfer Mode—Solution for Broadband ISDN, 2nd Edition, Ellis Horwood, 1993. Each of these references is incorporated herein by reference for all purposes.
Point-to-point connections between ATM nodes are made by “virtual circuits” or “virtual connections.” A virtual connection may be a permanent virtual circuit (PVC) (e.g., a fixed line) or by a switched virtual circuit (SVC) (a temporary virtual connection). Since an SVC is temporary, it is established between two network devices of the ATM network 100 upon demand and then released after a predetermined time period. Note that the connection may include temporarily combining two PVCs and on either side of a switch capable of connecting the two PVCs.
An ATM network device has an ATM address, such as a VPI address or a VCI address, which is required by a network device in order to establish the SVC with a second virtual device. The ATM address will sometimes be referred to herein as a Network Service Access Point (“NSAP”) Because PVCs dedicate network bandwidth to the two connected nodes (and preclude other nodes from using that bandwidth), PVC use is generally limited. Thus, to increase network applicability, many systems make use of SVCs. The process of establishing an SVC will be described broadly with respect to FIG. 1A.
FIG. 1A describes the process of establishing a virtual connection between a network device 104 and a network device 108. The network devices 104 and 108 have NSAP addresses of NSAP1 and NSAP2 respectively. To initiate the connection, the network device 104 constructs a ‘SETUP’ message 136 which indicates a desire to establish a connection with device 108, and sends it to the NSAP2 address. Message 136 may require multiple hops to reach device 108. To simplify the discussion, only a single hop is depicted here. As the SETUP message propagates toward its destination, the network acknowledges receipt of the message with CALL PROCEEDING messages at each hop. As shown, in FIG. 1B, network device 108 replies with a CALL PROCEEDING message 138 if it is merely a hop on the path to the ultimate destination or a CONNECT message 140 if it is the ultimate destination. In this case where NSAP2 is not the destination, another SETUP message is propagated to the next network device (not shown) along the path to the destination and a CALL PROCEEDING message returns from that device. This procedure continues until connection is made with the destination having NSAP2.
As the setup message 138 propagates to the eventual destination IP address along a number of network devices and switches, a PNNI protocol may be found. The destination may specify a set of protocol parameters of message transmission and return them with the CONNECT message. For example, an AAL5 platform with a 100 kBs bandwidth and a UBR service may be specified. If the network device 108 agrees to these parameters, the network device 108 will respond with a “CONNECT ACKNOWLEDGMENT” message 142. In this case, an SVC is established between NSAP1 and NSAP2 as well as between any additional switches along the pathway from NSAP2 to the destination. Once the virtual connections are established, data such as IP datagrams using ATM packets may be sent.
ATM can be used to run IP in a procedure referred to as IP over ATM. See Laubach, M. and Halpern, J., “Classical IP and ARP over ATM”, RFC 2225 , April 1998 (http://www.ietf.cnri.reston.va.us/home.html), which is incorporated herein by reference for all purposes. In IP over ATM, each ATM host in a set of hosts is assigned its own IP address. The set of ATM hosts forms a logical IP subnet (“LIS”) which acts as a virtual LAN. All members of a LIS are directly connected to the ATM network and have the same IP network/subnet number and address mask. Hosts on the same LIS may exchange IP packets directly, but hosts on different ones are required to go through a router. A LIS may act as a bridge connecting existing LANs.
To move IP packets along a route from source to destination, in a conventional non-ATM IP network, an Address Resolution Protocol (“ARP”) is used. See Plummer, D., “An Ethernet Address Resolution Protocol—or—Converting Network Protocol Addresses to 48.bit Ethernet Addresses for Transmission on Ethernet Hardware,” STD 37, RFC 826, November 1982 (which is incorporated herein by reference). In such protocol, a network device holding a packet to be delivered asks its peers which one of them is responsible for handling packets having the IP destination address of the packet. The device makes this inquiry via an “ARP packet.” The correct device replies via the Address Resolution Protocol with its hardware address. The device holding the packet then encapsulates that packet with a header indicating the hardware address of the responding device and sends the packet to it.
In SVC cases, devices must learn the ATM addresses of their peers in order to forward IP packets to them. The ARP protocol immediately suggests itself for this purpose. ARP, as currently implemented and described in RFC 826, requires a broadcast medium (e.g., Ethernet) on which to transmit the ARP request. ATM, which is a point-to-point protocol, cannot support ARP as described in RFC 826.
One suitable method for transmitting IP datagrams over an ATM network where the destination lower level address is unknown uses ATM Address Resolution Protocol (“ATMARP”) as described in RFC 2225. ATMARP determines the lower level address of the next network device along a suitable path when given the destination IP address. An ATMARP system is typically comprised of an ATMARP Server and numerous ARP Clients who require assistance in transmitting to a destination IP address.
The ATMARP Server is typically responsible for determining the ATM address of the next network device along a suitable path when given the destination IP address. An ATMARP Client having a packet with a destination IP address needs to determine which of its ATM peers should serve as the next hop. It determines this by sending an ATMARP request to the ATMARP server, which resolves the request and returns the ATM address of the ATMARP Client serving as the next hop.
FIG. 1B illustrates the components of an ATM network 100 capable of running IP over ATM. The ATM network 100 includes an ATMARP Server 102. The server 102 is responsible for facilitating associations between ATMARP Clients 104, 106 and 108. Physically, the server 102 as well as the clients 104, 106 and 108 may be any conventional network device including routers or bridges. They may also be conventional hosts configured to run ATM.
Because individual ATM network devices are incapable of broadcasting an ARP message, the ATMARP Server 102 acts in conjunction with the network devices to facilitate transmission to a destination IP address. For example, the ARP Server 102 may return the appropriate ATM address (NSAP) when given an IP destination request by the ARP Client 104. For this purpose, the server 102 and the network device 104 are shown to have a virtual connection 112.
As an example of ATMARP, consider an IP message from a node handled by device 104 to a node handled by device 108. Device 104 has the message with its associated destination IP address but does not know which of its ATM peers should act as the next hop. To identify this device, network device 104 (IP address 1) sends an ARP request over the virtual connection 112 to the ATMARP Server 102 requesting the ATM address of the device handling transmissions to the destination IP address (IP address 3). The server 102 determines that IP address 3 corresponds to NSAP address 3 (device 108) and then responds, along the connection 112, with an NSAP address (NSAP3) corresponding to network device 108 (IP address 3). The NSAP address corresponding to network device 108 provided by the server 102 allows the network device 104 to set up a virtual connection 114 with the network device 108 and thus send the data packet. Typically, the ATMARP Server 102 is capable of providing an ATM address for each network device it is connected to.
FIG. 2 illustrates a problem that can arise using the ATMARP protocol on an ATM network such as the ATM network 100 illustrated in FIG. 1B. ATMARP Clients 104, 106 and 108 are distinguishable by NSAP addresses NSAP1, NSAP2 and NSAP3 respectively. ATMARP Clients 104 and 108 are coupled to external networks (networks beyond ATM network 100) such as Internet 206 and a private local network 210. In the illustrated environment, the ATMARP Client 104 may be a gateway router leading to the Internet 206, which includes an entity 206 connected to the Internet 206. The ATMARP Client 108 connects with the local network 210, which includes various network nodes such as an arbitrary entity 212.
When a data packet is to be sent from entity 208 to the arbitrary entity 212, a series of steps is taken in order to establish the required network connections. First, the packet from entity 208 must proceed through the relevant connections in the Internet 206 to reach network device 104. At this point, the packet must proceed through the ATM network 100 to reach the ATMARP Client 108. If the virtual connection does not exist, then the corresponding low level NSAP address is required to establish a virtual connection 114. First, the Client 104 may check an internal cache (corresponding to a list of ATMARP entries that may have been stored) to find the low level NSAP address. If it is not in the internal cache, the ATMARP Client 104 relays an ATMARP request specifying the IP address of device 108 to the server 102.
At this point, the ATMARP Server 102 checks whether there is an existing NSAP address for the destination IP address in a cache which stores existing external responsibilities of the ARP Clients it is responsible for. The ATMARP Server responds with the NSAP address for ATMARP Client 108. After the ARP Client 104 receives the ARP response corresponding to the ARP Client 108 NSAP address, the ARP Client 104 proceeds to establish a virtual circuit 114 with the ARP Client 108 in the manner described in FIG. 1A.
Suppose that ARP Client 108 malfunctions, breaks down or temporarily shuts down for service, and thus the virtual connection 114 cannot be made. The data package is thus incapable of reaching its destination and communication with nodes on network 210 via ATM network 100 is impossible. If ARP Client 108 is the sole link for handling access to local network 206, local network 210 is essentially shut off from all external communication. This inability to communicate will persist until the faulty network device is corrected. As there may be hundreds of network devices relying on the ATM link through device 108, this inability to communicate through a single non-functioning network device seriously compromises the effectiveness of ATM switching systems.
In view of the foregoing, a technique for protecting against failure of a network device in an LIS running ATMARP would be highly beneficial.